In automated software testing, identifying software regressions typically involves the running of one or more test cases periodically against a set of builds created from the “Top-of-Tree” (ToT) revisions in a source code repository. In order to determine if functional (e.g. a failure) and non-functional (e.g. a drop in performance) regressions have occurred, test results may be compared to an expected set of results or against the results of a previous run of the test cases. Depending on the time between two consecutive runs of the test cases, there may be a significant number of revisions associated with the set of builds used by the test cases. Regression identification is to determine which revision between the last “good” revision and the first “bad” revision is responsible for the regression. There are a number of conventional approaches that can be applied to solve this “triaging” problem, including reading the change descriptions, dump analysis, statistics analysis, and log file inspection. However, these conventional approaches are time and/or resource intensive when a large number of revisions are involved.